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DETAILED ACTION 

1 . This Office Action is in response to Remarks and Amendments received 20 January 
2006. Per Applicant's request, claims 1, 2, 3, 5, 6, 7, 9, 12-17, 19, 20, 21, 23, and 26 have been 
amended. Claims 1-26 are pending. 

Specification 

2. In view of the amendments to the Specification, the prior objections are hereby 
withdrawn. 

Drawings 

3. In view of the amendments to the Specification, the prior objections are hereby 
withdrawn. 

Response to Arguments 

4. Applicant has argued, in substance, the following: 

(A) Regarding independent claim 1, as noted at the bottom of page 11, Broman "does not teach 
or disclose a system wherein a module can provide and use at least one API." Applicant argues 
that the Office Action has incorrectly correlated the term 'user interface components' with APIs. 

Examiner's Response: Examiner disagrees. The fact that user interface components exist in an 
application implies that they are used by Application Programming Interface code to 
communicate with program functionality. Broman disclosed (col. 2, line 66) a custom 
application project generator, that creates source file templates and user interface resources. Col. 
3, lines 28-35, the custom application project generator interfaces (application programming 
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interface functionality) with a generator services module. The generator services module 
provides services for basic user interface and application project generation functionality. Col. 3, 
line 33, "The custom application project generator and standard services module are interfaced 
by a framework which comprises a set of application program interfaces included in the 
standard services module and a set of class interfaces included in the custom application 
project generator." (emphasis added) 

(B) Regarding independent claim 1, as noted at the middle of page 12, Broman "does not teach 
or suggest a system that gathers application program interface (API) dependency information for 
each module." 

Examiner's Response: Thurston, more specifically disclosed metadata [0008-0009] to control 
installations and dependency information placed into 'constraints' that must be satisfied into a 
header. See FIG. 4. Thurston disclosed 'metadata' held in header files [0039-0041], including 
version number, names of dependent devices, size and checksums, and digital signature. 

Claim Rejections - 35 USC §103 
5. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 
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6. Claims 1-26 are rejected under 35 U.S.C. 103(a) as being unpatentable over US Patent 
5,754,858 to Broman et al., in view of US Patent Application Publication 2003/0217193 Al to 
Thurston et al. 

Per claim 1 : 

A method of a development and build environment for packaged software delivery in a 
distributed network of nodes, the method comprising the computer-implemented steps of: 
Broman disclosed a 'method' (col. 23, line 31 -col. 24, line 40) for "customizable automated 
application project generation (col. 4, lines 65-66) (development and build environment). 
Broman disclosed the 'network' suitability at col. 20, lines 52-63. 

-compiling source code files into executable file modules; 

Broman disclosed compiling source code at col. 6, lines 20-22, "The writer builds... from the 
source files. . .using a compiler. . ." 

-wherein a module contains an image for a process or a dynamically linked library (DLL); 
Broman disclosed dynamically linked libraries at col. 6, lines 27-32, ". . .links the object 
code. . .and .RES files together into a dynamic link library. . ." 

-creating a software package that comprises at least one module; 

Broman disclosed (Col. 6, lines 36-37) the custom application project generator creating the 
application project (software package comprising at least one module). 
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-wherein packages are created based on features/characteristics or purpose; 

Broman disclosed, as an example, (col. 8, lines 5-10) the package may be language specific 

(feature / characteristic / purpose). 

-creating metadata for a module that includes any module information such as the module's: 
binary signature, name, directory path, and characteristics; 

Broman disclosed (col. 7, line 55), as an example, a 'name' may be created. Also, col. 11, lines 
47-54, disclosed a services module generates a file named by destination-filename (name) which 
can contain a path (directory path). 

-inserting the module's metadata into the software package; 

Broman disclosed a 'newproj.inf template (col. 11, line 39) that contains created directories, 
whereby the directories are filled by the services module (col. 11, line 49). The services module 
lists files used to build the application (col. 11, lines 60-67). 

-gathering application program interface (API) dependency information for each module; 
Broman disclosed (col. 8, lines 25-28 & 44-45) a services module that presents a sequence of 
options for selection, suggestive of dependency compliance. A set of user interface controls for 
the user to choose from related applications project options. Col. 3, line 33, "The custom 
application project generator and standard services module are interfaced by a framework 
which comprises a set of application program interfaces included in the standard services 
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module and a set of class interfaces included in the custom application project generator." 
(emphasis added) 

-wherein a module can provide and use at least one API; 

Broman disclosed providing and using APIs, (col. 8, lines 38-48), as an example, the project 
generator and services module generate using templates (resource files - text or binary), where 
the binary files contain user interface components (toolbars and the like) which inherently 
communicate with the underlying program through APIs. At col. 8, line 10, a 'list box' control 
is used to select specific language support. Inherently there are Application Programming 
Interface functions that link (use at least one API) to the desired language module. Also, col. 17, 
line 24, API functions support language selection. Col. 3, line 33, "The custom application 
project generator and standard services module are interfaced by a framework which 
comprises a set of application program interfaces included in the standard services module 
and a set of class interfaces included in the custom application project generator." (emphasis 
added) 

Regarding the limitations: 

-collecting dependencies documented in module specifications. . .; 

Broman disclosed (col. 10, line 30) application project options, suggestive of dependencies. 
Also Broman disclosed (col. 11, lines 63-67) make files which list source code files that must be 
compiled (considering dependencies) to build the application. 
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-wherein the dependencies documented in each module lists API names and versions that the 
process or DLL depends on. 

Broman disclosed (col. 17, lines 1-24) template processing directives for the document where the 
module build inherently includes API names and versions (bitmap data for user interface 
components copied into the project-col. 8, lines 38-48) 

Broman disclosed 'dependency' information, but failed to disclose 'metadata'. 
However, Thurston, more specifically disclosed metadata [0008-0009] to control installations 
and dependency information placed into 'constraints' that must be satisfied into a header. See 
FIG. 4. Thurston disclosed 'metadata' held in header files [0039-0041], including version 
number, names of dependent devices, size and checksums, and digital signature. 

Therefore, it would have been obvious, to one of ordinary skill in the art, at the time of the 
invention to modify Broman's invention to include additional details in the component header 
such as names, versions, and dependency constraints, as disclosed by Thurston, because such 
information contained in a header file as meta data is useful for conveying relevant information 
when delivering software for installation. Thurston was motivated (Thurston -[0010]) to provide 
updates to support new and different types of devices in a manner to simplify development and 
maintenance. It would have been obvious, to one of ordinary skill in the art, at the time of the 
invention to modify Broman / Thurston, using Kramer, because Kramer provided support for 
software development [0004], allowing developers to maintain control the module dependency 
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structure in a pragmatic, cost effective way over the long lifetime of large-scale, development 
and maintenance projects. 

Per claim 2: 

-a linker creates a list of dependent modules for a given process or DLL module and places the 
list.... 

Broman disclosed a linker. See FIG. 2, #72 & #88. Broman disclosed (col. 8, lines 5-10 & 25- 
28) selectable option steps and selectable language resources, disclosing consideration to 
dependencies. The services module copies (col. 1 1, lines 55-60) template information to the 
project. Col. 11, lines 63-67, disclosed a 'make file' which lists source code files that must be 
compiled to build (list of dependent modules for a given process) the application. 

Broman disclosed 'dependency 5 information, and failed to disclose placing information into the 
'metadata'. 

However, Thurston, more specifically disclosed metadata [0008-0009] to control installations 
and dependency information placed into 'constraints' that must be satisfied into a header. See 
FIG. 4. Thurston disclosed 'metadata' held in header files [0039-0041], including version 
number, names of dependent devices, size and checksums, and digital signature. 

Therefore, it would have been obvious, to one of ordinary skill in the art, at the time of the 
invention to modify Broman's invention to include additional details of metadata in the 
component header, as disclosed by Thurston, because such information contained in a header file 
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as metadata is useful for conveying relevant information when delivering software for 
installation. Thurston was motivated (Thurston -[0010]) to provide updates to support new and 
different types of devices in a manner to simplify development and maintenance. 

Per claim 3: 

-creating metadata for each API; 

Broman disclosed (col. 9, lines 20-55) that a user is presented with options for creating an 
application project. The project generator and services module generate the application project 
using the template files / resource files. Template files / resource files contain text and binary 
files and macros and directives, which determine the content of the source files in the application 
project (provides metadata type information). Broman disclosed (col. 10, lines 3-12 & 31-33) 
'directives' guide the production of the application project, through a confirm.inf template. 

-inserting the API metadata into the software package; 

Broman disclosed (col. 11, lines 17-21) "The newproj.inf template contain the instructions 
(metadata type information inserted into package) that the services module uses to construct the 
application project. The instructions are statements, directives, and macros that work together to 
describe the structure of the application project." 

Regarding the limitation: 

-wherein metadata for an API includes, but is not limited to: the API's name and version. 
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Broman was suggestive of metadata included in the created application project, but failed to 
explicitly disclose metadata and contents. However Thurston disclosed metadata stored in a 
header portion [0008-0009] to be used to control installation of code. Thurston disclosed the 
header data could include a name, version, size, checksum, digital signature. 

Therefore, it would have been obvious, to one of ordinary skill in the art, at the time of the 
invention to modify Broman's invention to include additional details of metadata in the 
component header, as disclosed by Thurston, because such information contained in a header file 
as metadata is useful for conveying relevant information when delivering software for 
installation. Thurston was motivated (Thurston -[0010]) to provide updates to support new and 
different types of devices in a manner to simplify development and maintenance. 

Per claim 4: 

Bronson failed to disclose: 

-calculating a binary signature for each module and inserting the binary signature into the 
respective module's metadata; 

-wherein each unique version of a module will have a unique binary signature. 

However Thurston disclosed metadata stored in a header portion [0008-0009] to be used to 
control installation of code. Thurston disclosed the header data could include a name, version, 
size, checksum, digital signature (binary signature). Details including name, version, size, 
checksum contribute to a unique binary signature. 
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Therefore, it would have been obvious, to one of ordinary skill in the art, at the time of the 
invention to modify Broman's invention to include additional details of metadata in the 
component header, as disclosed by Thurston, because such information contained in a header file 
as metadata is useful for conveying relevant information when delivering software for 
installation. Thurston was motivated (Thurston -[0010]) to provide updates to support new and 
different types of devices in a manner to simplify development and maintenance. 

Per claim 5: 

Bronson failed to specifically disclose: 

-creating metadata for a package that includes any package information such as the packaged: 

name, build date, and characteristics; 

-inserting the package metadata into the package. 

However Thurston disclosed metadata stored in a header portion (inserting package metadata) 
[0008-0009] to be used to control installation of code. Thurston disclosed the header data could 
include a name, version, size, checksum, digital signature (binary signature). Details including 
name, version (build date), size, checksum (characteristics) contribute to a unique identity. 

Therefore, it would have been obvious, to one of ordinary skill in the art, at the time of the 
invention to modify Broman's invention to include additional details of metadata in the 
component header, as disclosed by Thurston, because such information contained in a header file 
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as metadata is useful for conveying relevant information when delivering software for 
installation. Thurston was motivated (Thurston -[0010]) to provide updates to support new and 
different types of devices in a manner to simplify development and maintenance. 

Per claim 6: 

A method of a development and build environment for packaged software delivery in a 
distributed network of nodes, the method comprising the computer-implemented steps of: 

-compiling source code files into executable file modules; 

-wherein a module contains an image for a process or a dynamically linked library (DLL); 

-creating a software package that comprises at least one module; 

-creating metadata for a module that includes any module information such as 

the module's: binary signature, name, directory path, and characteristics; 

-inserting the module's metadata into the software package; 

-gathering application program interface (API) dependency information for each module; 
-wherein a module can provide and use at least one API. 

See rejection of limitations as addressed in claim 1 above. 

Per claim 7: 

-wherein a linker creates a list of dependent modules for a given process or DLL module and 
places the list in the module's metadata. 
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See rejection of limitations as addressed in claim 2 above. 
Per claim 8: 

-collecting dependencies documented in module specifications and placing them into the 
module's metadata; 

-wherein the dependencies documented in each module lists API names and versions that the 
process or DLL depends on. 

See rejection of limitations as addressed in claim 1 above. 
Per claim 9: 

-creating metadata for each API; 

-inserting the API metadata into the software package; 

-wherein metadata for an API includes, but is not limited to: the API's name and version. 
See rejection of limitations as addressed in claim 3 above. 

Per claim 10: 

-calculating a binary signature for each module and inserting the binary signature into the 
respective module's metadata; 

-wherein each unique version of a module will have a unique binary signature. 
See rejection of limitations as addressed in claim 4 above. 



Per claim 1 1 : 
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-packages are created based on features/characteristics or purpose. 
See rejection of limitations as addressed in claim 1 above. 

Per claim 12: 

-creating metadata for a package that includes any package information such as the packaged: 

name, build date, and characteristics; 

-inserting the package metadata into the package. 

See rejection of limitations as addressed in claim 5 above. 

Per claim 13: 

An apparatus for a development and build environment for packaged software delivery in a 
distributed network of nodes, comprising: 

Bronson disclosed a 'system' (apparatus) (col. 4, lines 64-66) providing an automated 
application project generation (a development and build environment). 

-means for compiling source code files into executable file modules; 

-wherein a module contains an image for a process or a dynamically linked library (DLL); 

-means for creating a software package that comprises at least one module; 

-means for creating metadata for a module that includes any module information such as the 

module's: binary signature, name, directory path, and characteristics; 

-means for inserting the module's metadata into the software package; 
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-means for gathering application program interface (API) dependency information for each 
module; 

-wherein a module can provide and use at least one API. 
See rejection of limitations as addressed in claim 1 above. 

Per claim 14: 
-a linker; 

-wherein said linker creates a list of dependent modules for a given process or DLL module and 

places the list in the module's metadata. 

See rejection of limitations as addressed in claim 2 above. 

Per claim 15: 

-means for collecting dependencies documented in module specifications and placing them into 
the module's metadata; 

-wherein the dependencies documented in each module lists API names and versions that the 
process or DLL depends on. 

See rejection of limitations as addressed in claim 1 above. 
Per claim 16: 

-means for creating metadata for each API; 

-means for inserting the API metadata into the software package; 

-wherein metadata for an API includes, but is not limited to: the API's name and version. 
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See rejection of limitations as addressed in claim 3 above. 
Per claim 17: 

-means for calculating a binary signature for each module and inserting the binary signature into 
the respective module's metadata; 

-wherein each unique version of a module will have a unique binary signature. 
See rejection of limitations as addressed in claim 4 above. 

Per claim 18: 

-packages are created based on features/characteristics or purpose. 
See rejection of limitations as addressed in claim 1 above. 

Per claim 19: 

-means for creating metadata for a package that includes any package information such as the 

package's: name, build date, and characteristics; 

-means for inserting the package metadata into the package. 

See rejection of limitations as addressed in claim 5 above. 

Per claim 20: 

A computer-readable medium carrying one or more sequences of instructions for a development 
and build environment for packaged software delivery in a distributed network of nodes, which 
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instructions, when executed by one or more processors, cause the one or more processors to 
carry out the steps of: 

-compiling source code files into executable file modules; 

-wherein a module contains an image for a process or a dynamically linked library (DLL); 
-creating a software package that comprises at least one module; 

-creating metadata for a module that includes any module information such as the module's: 
binary signature, name, directory path, and characteristics; 
-inserting the module's metadata into the software package; 

-gathering application program interface (API) dependency information for each module; 
-wherein a module can provide and use at least one API. 

This is a 'computer readable medium' version of claim 1. See FIG. 2 where the instructions for 
development are shown located on a system. See rejection of limitations as addressed in claim 1 
above. 

Per claim 21: 

-wherein a linker creates a list of dependent modules for a given process or DLL module 

and places the list in the module's metadata. 

See rejection of limitations as addressed in claim 2 above. 



Per claim 22: 
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-collecting dependencies documented in module specifications and placing them into the 
module's metadata; 

-wherein the dependencies documented in each module lists API names and versions that the 
process or DLL depends on. 

See rejection of limitations as addressed in claim 1 above. 
Per claim 23: 

-creating metadata for each API; 

-inserting the API metadata into the software package; 

-wherein metadata for an API includes, but is not limited to: the API's name and version. 
See rejection of limitations as addressed in claim 3 above. 

Per claim 24: 

-calculating a binary signature for each module and inserting the binary signature into the 
respective module's metadata; 

-wherein each unique version of a module will have a unique binary signature. 
See rejection of limitations as addressed in claim 4 above. 

Per claim 25: 

-packages are created based on features/characteristics or purpose. 
See rejection of limitations as addressed in claim 1 above. 
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Per claim 26: 

-creating metadata for a package that includes any package information such as the package's: 
name, build date, and characteristics; and inserting the package metadata into the package. 
See rejection of limitations as addressed in claim 5 above. 

Conclusion 

7. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

8. The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure. 



Note: US Patent Application Publication 2004/0133875 Al to Kramer 
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Kramer disclosed [0032] a "rules-based module architecture checking system for compliance 
checking to monitor dependencies between software components. Also see Kramer, FIG. 3. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Mary Steelman, whose telephone number is (571) 272-3704. The 
examiner can normally be reached Monday through Thursday, from 7:00 AM to 5:30 PM If 
attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Wei 
Zhen can be reached at (571) 272-3708. The fax phone number for the organization where this 
application or proceeding is assigned: 571-273-8300. 

Any inquiry of a general nature or relating to the status of this application should be 
directed to the TC 2100 Group receptionist: 571-272-2100. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 



Mary Steelman 



04/11/2006 





